1. Field of the Invention
The present invention relates to the field of software development tooling and, more particularly, to representing models in SDLC tools using a network of Internet resources.
2. Description of the Related Art
A Systems Development Life Cycle (SDLC) is a collection of process, methods, and tools used by various roles to develop an information system, including requirements, validation, training, and user ownership through investigation, analysis, design, implementation, and maintenance. Required artifacts in the SDLC can be modeled using a variety of software modeling tools and standards, such as the Systems Modeling Language (SysML), Integrated DEFinition (IDEF), Entity Relationship Diagrams (E/R), Unified Modeling Language (UML), processing modeling tools, and the like. Each of these tools manage a set of associated artifacts, where an artifact is a software construct that represents any logical or physical asset created or maintained through a SDLC. For descriptive purposes, a model is a type of artifact with a structured representation used by modeling tools.
SDLC tooling can be analyzed in terms of the following general requirements: scalability, interoperability, extensible model representations, and traceability within and between models. Scalability refers to an ability of a solution to support hundreds of thousands, if not millions, or artifacts in its repository without unreasonable measures being taken. Interoperability, which can be realized in a SDLC context through open APIs, ensures that users are not locked into a specific tooling provided by a repository vender, which can increase purchase and maintenance costs, can be limiting in terms of utilization of emerging technologies, and can result in other problems typical of a lock-in situation. An extensible model representation describes models in a manner that permits them to carry and utilize additional information, such as information contributed by an additional tool or end-user. Extensible tools should have an ability to validate added content. Traceability within and between models refers to an ability of an approach to satisfy user needs to express and understand relationships between models and other SDLC artifacts. Relationships can include peer relationships (e.g., a customer having multiple accounts for which particular SDLC artifacts relate), temporal relationships (e.g., an artifact was created from another artifact), and trace relationships (e.g., showing which SDLC artifacts are associated with which sets of requirements).
Conventional SDLC modeling tools manage artifacts using either a database storage approach or a file system and version control system approach, each of which has significant shortcomings. FIG. 1 (Prior Art) illustrates a conventional database storage approach 110 and a conventional model file approach 140 for storing and managing SDLC artifacts.
The database storage approach 110 provides tools that operate in a client-server configuration, where information is stored in tables 112, 114 of a server database 116. An underlying schema for artifacts is fixed in advance and tools read/write to specific tables in a shared database 116. Since approach 110 relies upon a database foundation, it is as scalable as the underlying database 116 upon which it is constructed. Similarly, API's used for approach 110 depend upon those of an underlying database. Extensibility and traceability of approach 110 can require a restructuring of underlying database structures, which can be expensive and time consuming. Additionally, many database implementations include proprietary codes and structural constraints, which can make user desired modifications difficult. Further, user interfaces built on top of a database can require changes as a database structure changes.
A file and version control system (VCS) approach 140 can create artifacts on the file systems of the user's machines, which results in artifacts being stored in a set of storage spaces 142-149. These storage spaces 142-149 can be “nested” by designating a set of spaces 142, usually geographically grouped at a location having a primary function related to the type of artifact being stored. Within any set of spaces 142, numerous sub-spaces 144, 146 can exist. Searching for a given artifact can require searching through all the storage spaces 142-149. This searching can be “optimized” by grouping different types of artifacts so that only a subset of the storage spaces need be searched for a given type of artifact, such as searching space 142. This “optimization” assumes that a user's search criteria matches criteria through which the artifacts are grouped. Sometimes, a complete index of files in spaces 142-149 is maintained by a set of one or more servers. Approach 140 generally scales poorly and performance degrades quickly as an overall artifact quantity increases. Approach 140 often uses proprietary code and APIs, with variable extensibility characteristics depending upon coding practices used to implement an instance of approach 140. Most conventional solutions following approach 140 have limited to no traceability within and between models.